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The Space Shuttle Ascent Flight Design team is responsible for defining a launch to orbit 
trajectory profile that satisfies all programmatic mission objectives and defines the ground 
and onboard reconfiguration requirements for this high-speed and demanding flight phase. 
This design, verification and reconfiguration process ensures that all applicable mission 
scenarios are enveloped within integrated vehicle and spacecraft certification constraints 
and criteria, and includes the design of the nominal ascent profile and trajectory profiles for 
both uphill and ground-to-ground aborts. The team also develops a wide array of associated 
training, avionics flight software verification, onboard crew and operations facility products. 
These key ground and onboard products provide the ultimate users and operators the 
necessary insight and situational awareness for trajectory dynamics, performance and event 
sequences, abort mode boundaries and moding, flight performance and impact predictions 
for launch vehicle stages for use in range safety, and flight software performance. These 
products also provide the necessary insight to or reconfiguration of communications and 
tracking systems, launch collision avoidance requirements, and day of launch crew targeting 
and onboard guidance, navigation and flight control updates that incorporate the final 
vehicle configuration and environment conditions for the mission. 


Over the course of the Space Shuttle Program, ascent trajectory design and mission 
planning has evolved in order to improve program flexibility and reduce cost, while 
maintaining outstanding data quality. Along the way, the team has implemented innovative 
solutions and technologies in order to overcome significant challenges. A number of these 
solutions may have applicability to future human spaceflight programs. 


One area of difficulty has been offering the Program the flexibility that it desires. The 
Space Shuttle is an incredibly capable vehicle, making possible a wide variation in payload 
configurations and mission objectives. This can pose a challenge, especially for human 
missions. For example, it is necessary to provide flight crews with pre -flight training, and 
this drives designs to be completed well in advance of the launch date. Often, mission 
requirements will change between this initial design and flight, and launches can slip. The 
Ascent Flight Design team has implemented processes much closer to launch which allow for 
late updates to ground and onboard assets at minimal cost. 


Another challenge has been the management of a large volume of fundamental technical 
change, such as the evolution of ascent nominal and abort trajectory and flight software 
capabilities, improvements required to increase program flexibility, and the ever-present 
challenge to increase payload to orbit. The Ascent Flight Design team has implemented 
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processes to ensure the impacts and implementation of such changes are properly 
coordinated amongst a variety of stakeholders. 


Another focus has been the sustaining engineering required to maintain quality in a time 
of cost reductions and content additions. The Ascent Flight Design team has implemented 
rigorous process control on its procedures and software tools to ensure quality. In addition, 
the team has expanded its breadth of responsibility to include items such as the program- 
assigned requirements ownership of key ascent guidance, navigation and onboard display 
flight software principal functions and initialization data. 


The Space Shuttle Ascent Flight Design process has evolved with a significant increase in 
scope and content over the life of the program. The team has encountered and overcome 
obstacles that any other organization performing trajectory design for human missions are 
likely to encounter. The track record of outstanding quality, timeliness, and cost reductions 
points to a number of lessons learned which may be useful in shaping future, similar 
processes. 
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The Space Shuttle Ascent Flight Design team is responsible for defining a launch to orbit 
trajectory profile that satisfies all programmatic mission objectives and defines the ground 
and onboard reconfiguration requirements for this high-speed and demanding flight phase. 
This design, verification and reconfiguration process ensures that all applicable mission 
scenarios are enveloped within integrated vehicle and spacecraft certification constraints 
and criteria, and includes the design of the nominal ascent profile and trajectory profiles for 
both uphill and ground-to-ground aborts. The team also develops a wide array of associated 
training, avionics flight software verification, onboard crew and operations facility products. 
These key ground and onboard products provide the ultimate users and operators the 
necessary insight and situational awareness for trajectory dynamics, performance and event 
sequences, abort mode boundaries and moding, flight performance and impact predictions 
for launch vehicle stages for use in range safety, and flight software performance. These 
products also provide the necessary insight to or reconfiguration of communications and 
tracking systems, launch collision avoidance requirements, and day of launch crew targeting 
and onboard guidance, navigation and flight control updates that incorporate the final 
vehicle configuration and environment conditions for the mission. 


Over the course of the Space Shuttle Program, ascent trajectory design and mission 
planning has evolved in order to improve program flexibility and reduce cost, while 
maintaining outstanding data quality. Along the way, the team has implemented innovative 
solutions and technologies in order to overcome significant challenges. A number of these 
solutions may have applicability to future human spaceflight programs. 


One area of difficulty has been offering the Program the flexibility that it desires. The 
Space Shuttle is an incredibly capable vehicle, making possible a wide variation in payload 
configurations and mission objectives. This can pose a challenge, especially for human 
missions. For example, it is necessary to provide flight crews with pre-flight training, and 
this drives designs to be completed well in advance of the launch date. Often, mission 
requirements will change between this initial design and flight, and launches can slip. The 
Ascent Flight Design team has implemented processes much closer to launch which allow for 
late updates to ground and onboard assets at minimal cost. 


Another challenge has been the management of a large volume of fundamental technical 
change, such as the evolution of ascent nominal and abort trajectory and flight software 
capabilities, improvements required to increase program flexibility, and the ever-present 
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challenge to increase payload to orbit. The Ascent Flight Design team has implemented 
processes to ensure the impacts and implementation of such changes are properly 
coordinated amongst a variety of stakeholders. 


Another focus has been the sustaining engineering required to maintain quality in a time 
of cost reductions and content additions. The Ascent Flight Design team has implemented 
rigorous process control on its procedures and software tools to ensure quality. In addition, 
the team has expanded its breadth of responsibility to include items such as the program- 
assigned requirements ownership of key ascent guidance, navigation and onboard display 
flight software principal functions and initialization data. 


The Space Shuttle Ascent Flight Design process has evolved with a significant increase in 
scope and content over the life of the program. The team has encountered and overcome 
obstacles that any other organization performing trajectory design for human missions are 
likely to encounter. The track record of outstanding quality, timeliness, and cost reductions 
points to a number of lessons learned which may be useful in shaping future, similar 
processes. 


I. Introduction 

T HE Ascent Flight Design (AFD) team has made significant contributions to the success of the Space Shuttle 
Program (SSP). This paper will describe and explore some of the challenges the team has encountered 
throughout the 135 Space Shuttle missions, and some of the strategies used to overcome them. It will also 
briefly outline additional lessons learned based on the AFD experience. 

II. Moving the work as late as possible 

The Space Shuttle was an incredibly capable vehicle in the sense that it could accommodate a very wide variety of 
missions. Orbital inclination, orbital altitude, propellant loads, and mass properties such as longitudinal center of 
gravity (CGx), Orbiter and overall integrated vehicle weights, and launch environment could vary dramatically from 
mission to mission, and each of these factors could have a significant influence on the no-fail ascent and ascent/entry 
abort trajectory design and design dependent trajectory and ground systems products. As a result, it was important to 
perform a detailed trajectory design for each new mission. 

A. The Base Template 

The SSP utilized several different generic templates to guide and schedule the flight preparation process. Key 
milestones pertaining to the ascent flight design from a typical template used late in the Program, called the “base” 
template, are shown in Table 1. 


Table 1: Key milestones from the base template 


Milestone 

Schedule tie 

Description 

Mission baselining milestone 

Faunch minus 
(F-) 378 days 

A mission is considered formally baselined after it is 
added to the Flight Definition and Requirements 
Directive (FDRD; NSTS-07700 Volume III) 

Trajectory Design Data Package 
(TDDP) delivery 

F-303 days 

TDDP contains key information describing the mission 
profile and vehicle configuration 

Flight Operations Panel (FOP) 
meeting 

F-288 days 

Meeting sets the groundrules and constraints to be used 
in the trajectory and Initialization Foad (I-Foad) design 

I-Foad Submit 

F-233 days 

Values for ah I-Foads are submitted to the Space Shuttle 
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Program for approval 

I-Load Approval 

L-210 days 

All I-Load values for the mission are approved; the 
values will be incorporated into the mission Flight 
Software (FSW) in downstream processes 

Shuttle Mission Simulator (SMS) 
and Mission Control Center (MCC) 
Load Releases 

L-127 days 

Final step in the process to configure the SMS and MCC 
for mission- specific use 

Ready-for-training milestone 

L-126 days 

Shuttle Mission Simulator (SMS) and Mission Control 
Center (MCC) are ready; crew and flight controller 
training can begin 


The seven week period between the FOP meeting and the I-Load Submit milestone represented the time when AFD 
was performing its trajectory design and determining appropriate values for each of the Initialization Loads (I- 
Loads) for which it was responsible. During these seven weeks, AFD was on the critical path of the overall flight 
preparation process. On any given mission, roughly 1,650 AFD-owned I-Load values were designed or selected, 
then verified, in dependent order. For perspective, this represents -16% of the -10,050 I-Loads that were submitted 
for the reconfiguration of the flight software (FSW) mass memory for a single Space Shuttle mission, and more 
importantly represents a high percentage of the mission-to-mission unique trajectory design parameter updates. I- 
Loads that were planned for the ascent nominal (no-fail) mission were designed and verified first. Next, I-Loads that 
were planned for the ascent intact abort trajectories were designed and verified in parallel, followed by contingency 
abort I-Load verification for key representative trajectories. Finally, onboard display I-Loads for both ascent 
nominal and abort scenarios were designed and verified last. 

AFD I-Load design and verification involved a thorough examination. Automated tools were developed to check a 
wide array of SSP certification envelopes and constraints. Extensive numbers of trajectory cases were run where it 
was appropriate to do so, considering such factors as iterations on variables like guidance targets, systems 
constraints and criteria, abort performance boundaries, Space Shuttle Main Engine (SSME) failure points in the 
engine-out window, landing site, and SSME failed configuration (sequential or simultaneous). 

Work in AFD continued after I-Load Submit to supply key technical and facility data to multiple customers across 
the country, including preparation of data to support training and real-time operations in the SMS and MCC. 
Additional data products were prepared to support customers internal to the SSP such as the flight Software 
Production Facility (SPF) and customers external to the SSP such as the Air Force/45 th Space Wing (Range Safety). 

As the schedule in Table 1 illustrates, the core ascent I-Load design was essentially complete about seven months 
prior to launch, in order to support mission-specific crew and flight controller training activities that began about 
four months prior to launch. However the I-Loads and associated trajectory products, being sensitive to changes in 
mission parameters such as launch environment, mass properties and propellant loadings, were frequently reassessed 
throughout the template as driving changes to the mission definition baseline were made. Often, to address 
constraint or criteria margin violations or to improve constraint margin, and to protect against further mission 
requirements changes or launch slips, these reassessments resulted in the need to redeliver data products and/or I- 
Loads to incorporate the mission definition changes. 

B. Template improvement: Flight Operations Reinvention and ISS Standardization 

Recognizing that frequent design reassessments and product redeliveries were a cost and resource driver, process 
improvements were made. One of the most fundamental improvement efforts was called the Flight Operations 
Reinvention (“Reinvent”) initiative. Reinvent was primarily active in the years 1998 to 2002 and was in direct 
support of an SSP initiative to “Reinvent processes/standards to increase manifest flexibility.” Reinvent emerged at 
a goals and objectives meeting conducted by the SSP Manager in April 1998, and was the term used to categorize 
the last two levels of the “7 Levels of Change” i.e., Level 6 (Different - Do things that haven’t been done) and Level 
7 (Impossible - Do things that can’t be done). At that meeting, a “change example” was given of moving the 
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baseline milestone when a flight and cargo is approved in the Flight Definition and Requirements Directive (FDRD) 
from 12 months to 7 months prior to launch. SSP approval of the flight in the FDRD indicates that flight production 
can start. By the time Reinvent efforts were considered, the SSP had flown nearly 100 missions. Equivalent to the 
flight rate leading up to the launches of STS-61C and STS-51L/Challenger in January 1986, the Space Shuttle flight 
rate once again peaked at 10 flights flown between the launch of STS-70 on 6/27/1995 and launch of STS-78 on 
6/20/1996. Processes being utilized then evolved out of a development program and were generally based on 
experience from expendable vehicle programs. At the element and sub -element level, processes were honed and 
improved. New processes were added, and others were modified as the SSP evolved. As a result, mission related 
processes were revised that had not been evalulated based on what was most operationally effective across all 
elements. Up to that point, processes lacked flexibility in handling dynamic manifests, higher flight rates, changes 
to baselined mission requirements, and hardware modifications. Maintaining and increasing SSP flexibility had 
been a significant challenge while upgrading aging vehicles and facilities, incorporating safety modifications, and 
ensuring manned access to space under tight budget constraints. The Reinvent vision was to preserve a unique 
capability and provide safe and reliable access to space, revitalize the SSP as a foundation for future agency 
endeavours, enable increased availability of Shuttle launch services, expand program flexibility through process 
enhancement and modern technology, and provide launch services that meet or exceed the customer’s requirements 
for safety, performance, schedule and cost. As such, SSP goals and Reinvent objectives and strategies were tightly 
linked. 

Figure 1 below provides a simplified overview of SSP mission processes affected by the Reinvent effort. The AFD 
work discussed in this paper is largely contained in the top line labeled “Flight Design.” As one can see, AFD’s 
work is only one component of the overall process. 
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Figure 1: Flight Operations Reinvent Overview (CY 2000) 


Specifically applicable to ascent/entry trajectory design processes, the reinvent effort sought changes to flight 
operations processes, tools, and work content such that the 12-month base template could be replaced with a 7- or 8- 
month template, depending on the mission complexity and whether a similar mission had been recently designed. 
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One component of Reinvent was called ISS Standardization, which sought to rearrange the template by removing 
training support products from the critical path by using standardized I -Loads and data products for missions to the 
International Space Station (ISS). These standardized I-Loads and products were to be used for generic crew and 
flight controller training. Later in the template, after all major manifest and mission requirements had been finalized, 
the mission specific ascent (and entry) designs could be completed. Delaying the ascent / entry designs closer to 
launch would reduce the probability of late changes requiring reassessments and rework. 

The result of ISS Standardization was a new template, which delayed the ascent / entry I-Load designs. Key 
milestones of this new “ISS Standardization” template are shown in Table 2. The corresponding schedule ties from 
the old “base” template are also shown for comparison purposes. 


Table 2: Key milestones from the ISS Standardization and Base templates 


Milestone 

Schedule - ISS Standardization 

Schedule - Base 




Trajectory Design Data Package 
(TDDP) delivery 

L-198 days 

L-303 days 

Flight Ops Panel (FOP) meeting 

L-178 days 

L-288 days 

I-Load Submit 

L-128 days 

L-233 days 

I-Load Approval 

L-105 days 

L-210 days 

Shuttle Mission Simulator (SMS) 
and Mission Control Center (MCC) 
Load Releases 

L-29 days 

L-127 days 

Ready-for-training milestone 

L-28 days 

L-126 days 


As illustrated in Table 2, the ready-for-training milestone was delayed by 14 weeks (98 days) from L-126 days on 
the base template to L-28 days on the ISS Standardization template. This allowed the start of the ascent / entry 
designs, represented by the FOP milestone, to be delayed by more than 15 weeks (110 days) from L-28 8 days to L- 
178 days. So while mission-specific ascent / entry training was not eliminated entirely, it was significantly delayed. 
This had the desired effect of reducing ascent product rework, since the overall mission profile had nearly 4 extra 
months to mature before the design was started. 


C. Process improvement: Just-in-time Flight Design 

Another component of Reinvent was called Just-in-time Flight Design (JITFD). The JITFD project was 
implemented with the belief and slogan “Do it once, get it right.” Previous US human spaceflight programs had 
similar such beliefs as can be seen in Figure 2 with the Project Mercury stamp that was key to the then new manned 
flight awareness program, and the Project Gemini motivational poster that includes the slogan “Do it right... the first 
time.” 2 
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Figure 2: Manned Flight Awareness: Mercury Stamp, Gemini Motivational Poster 
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JITFD was worked in conjunction with ISS Standardization, and focused on creating a more efficient flight design 
process by reducing the number of internal hand-offs, redundant quality assurance (QA) steps, and duplication of 
efforts that had crept into the system over the duration of the SSP. JITFD resulted in significant structural 
improvements to the flight design process, including the introduction of a method to pre-select off-the-shelf I-Load 
values to start with the best starting point as the basis of the design effort. After a transition from legacy computer 
systems using main frame centralized computing facilities to the more powerful and versatile client/server network 
by 1992, the team also took further advantage of parallel processing capabilities across the mission planning system 
to process a high number of trajectory scan iterations for nominal ascent, ascent/entry abort and External Tank (ET) 
entry trajectories. In some cases, intensive efforts that were performed on ascent abort trajectory design and 
performance iteration sub-processes had been reduced from what was 12 weeks early in the program to only a few 
days thus taking these off the critical path. Other process changes were made which allowed the overall 7-week I- 
Load design period to be completed in no more than 5 weeks, a 28% reduction in process cycle time. These process 
improvements also allowed much quicker technical assessments and support of fast-track analyses to explore 
generic and mission-specific options for the Space Shuttle Program. Figure 3 below provides an overview of the 
Reinvent project roadmap, showing key initiatives across all mission processes including the JITFD project. 



Figure 3: Flight Operations Reinvent Project Roadmap 
D. Process improvement: Expanded GNC parameter uplink capabilities 

I-Load “uplinks” are used to overwrite I-Load values resident in the FSW with a new value. For the ascent flight 
phase, uplinks were used on launch day, shortly before liftoff, to reset the FSW with applicable launch targeting 
parameters that had been recalculated for the actual launch date and time. 

For much of the SSP duration, ascent-related I-Load uplinks were extremely limited. Due to the cost of 
implementation and cost/benefit implications, only a small subset of the ~ 10,050 I-Loads were available for uplink 
to the Primary Avionics Software System (PASS) and Backup Flight System (BFS) during prelaunch operations. 
For more than the first half of the 30-year Shuttle program, initial capabilities for ascent GNC parameter uplinks 
were primariliy limited to the nominal ascent trajectory especially the ascent GNC uplinks on day-of-launch for the 
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first stage pitch and yaw attitude profile, measured winds, SSME throttle bucket, orbital plane steering targets and 
Orbital Maneuvering System (OMS) insertion burn targets. However, ascent I-Load uplink capabilities were 
strategically expanded beginning with Operational Increment (OI)-26 (incremental releases of space shuttle FSW 
were designated by the 01 number), which introduced the ability to improve ascent performance by burning the 
OMS engines during second stage. I-Loads controlling the burn duration, as well as I-Loads controlling OMS burns 
for Abort To Orbit (ATO) aborts during the same time frame, were uplinkable. With 01-28, the capability was 
added to uplink I-Loads related to second stage nominal and aborts scenarios, specifically integrated vehicle and 
Orbiter guidance masses, SSME throttle level limits, and sequencing I-Loads to control abort Return-to-Launch-Site 
(RTLS) and Transatlantic Abort Landing (TAL) dumps. Finally, with 01-29, the capability was added to uplink 
additional I-Loads controlling functionality such as the nominal Main Engine Cut-Off (MECO) velocity and flight 
path angle targets and key guidance and sequencing parameters supporting the integrated ascent/entry design for the 
RTLS, TAL and uphill aborts. 

By the first flight using 01-29 flight software (STS-110, which launched on 4/08/2002), modifications to flight 
software and ground systems resulted in the ability to uplink a comprehensive set of ascent GNC I-Loads that were 
especially sensitive to late manifest changes. Since the I-Loads could be uplinked directly to the vehicle on launch 
day, they could be redesigned much closer to launch as compared to the planned I-Load Submit milestone which 
significantly improved SSP flexibility. 

E. Process improvement: Late design cycle 

Prior to expanding the uplinkable I-Loads, the paradigm was to assess each mission configuration change as it was 
approved. If an issue was discovered, and I-Load values needed to be updated, an “I-Load Patch” was required. An 
I-Load Patch involved formally submitting the new I-Load values for independent engineering verification, and 
then having the FSW organization build a new version of the flight- specific software including the new I-Load 
values. This so-called “complementary FSW load,” or Comp Load, was then thoroughly tested in the SPF and 
Shuttle Avionics Integration Laboratory (SAIL) prior to flight with these late changes. Examples of such late 
changes include TAL/ ATO abort gap closure efforts, launch slips into the new calendar year that affect time- 
dependent ascent guidance and navigation parameters, changes in abort landing site runway designations and 
navigation data, late breaking abort analysis affecting flight dynamics performance, unplanned payload weight 
growth or late significant deviations from control masses, late ET disposal footprint margin issues, late glide RTLS 
loads issues and “what-if ’ assessments to offload secondary payloads due to readiness issues such as offloading the 
AMS payload from the STS-91 mission (imposing a reduction in approximately 7000 lb of payload). 

AFD instituted an abbreviated design cycle, beginning only 30 days prior to launch and lasting only two weeks, to 
redesign the new uplinkable I-Loads. The final two weeks were reserved to allow for independent flight readiness 
verification by the systems integration organization and to allow for program systems integration technical reviews 
in support of the Certification of Flight Readiness (CoFR) process. This changed the paradigm such that changes 
now could be monitored continuously during the flight production timeline for applicability to this late design and 
verification cycle when the design was thoroughly evaluated, documented and statused for certification of flight 
readiness reporting. This not only saved resources, but significantly reduced the need to update ascent/entry 
guidance and sequencing I-Loads via lengthy I-Load patch reconfiguration, patch verification and testing processes 
in the SPF and the SAIL. This late update process in conjunction with the expanded capability to update key ascent 
GNC parameters via uplink was clearly beneficial to the ISS assembly missions, and was made available just at the 
right time when the frequency of unplanned ascent GNC I-Load patches was reaching a peak in 2001. The mission 
planning teams were able to utilize the full complement of such late update capabilities in support of the last 10 
years of Space Shuttle missions. 

Summary / Key Takeaways 

The SSP has matured in reliability and cost of operations due to evolutionary improvements of the mission planning 
process that allowed the trajectory design to be performed as close to launch as possible, ideally after all critical 
mission attributes have been frozen. 

• One key enabler for performing the design late is to decouple the mission specific trajectory design from 

crew and flight controller training. 

• A second key enabler is to have a short-duration design process. 

• A third key enabler is the capability to update the trajectory-related I-Loads close to launch, via uplink. 
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III. Implementing change management processes 

Because the success of a program is rooted in its ability to control its processes, evolve and grow to reduce cost and 
improve reliability/operability, the implementation of change management processes is critical. The data that AFD 
was responsible for was dependant on numerous information sources from multiple organizations throughout the 
SSP. For example, AFD trajectory simulation tools needed to model hardware systems owned by the Orbiter, ET, 
and Solid Rocket Booster (SRB) elements, AFD data products needed to properly reflect ET, OMS and Reaction 
Control System (RCS) propellant loading information that originated at Kennedy Space Center (KSC) Ground 
Operations, AFD I-Loads needed to conform to the constraints dictated by the Systems Engineering and Integration 
organization, and the processes established by the FSW organization. As a result, a change in nearly any corner of 
the SSP could ripple into AFD and create an impact to software tools, design processes, or personnel training. 

During these years, it was common for the ascent/entry flight design team to actively support, monitor and integrate 
at over 90 technical, planning and control board meetings with most meeting weekly. These meetings covered 
mission planning, flight operations, flight software, Orbiter specific, systems integration and program technical 
review and control boards, among others. It was imperative that AFD develop good systems engineering habits and 
change management processes in order to stay effective. Another consideration in support of a human spaceflight 
system was the sheer size of the flight design mission planning process that included hundreds of software tools, 
thousands of engineering and software documents and required the generation of thousands of analyses and mission 
products over the years. To maintain safety in such a complex mission planning environment, the application of 
proper mission design, constraint definition, trajectory control limits, and operational procedures is essential. This 
was the case for Projects Mercury, Gemini and Apollo 1 . The change management that accompanies these efforts is 
equally crucial. 

A. Examples of changes 

Changes that impacted AFD through the life of the SSP are too numerous to list, however a few examples can be 
used to illustrate the point. Some changes originated at the SSP level, including hardware changes like ET 
modifications, which drove AFD analysis of rupture altitudes and debris disposal zones. Another consistent area of 
such change was ascent aborts. Each space shuttle mission was designed to ensure that a certified abort could be 
performed at any time during the ascent flight phase. Over time, the abort options available to the crew on a 
particular mission evolved. For instance, the Transoceanic Abort Landing (TAL) abort mode was introduced early in 
the SSP to eliminate the need for an overlap between the RTLS and ATO abort modes. TAL landing sites were 
originally optimized for 28.5 degree inclination missions, and included such runways as Ben Guerir in Morocco, 
Moron in Spain, and Banjul in Gambia. Later, TAL landing sites were optimized by the SSP for 51.6 degree 
inclination missions headed to the ISS, so Istres, France was added. Introducing Istres as a new TAL landing site 
required not only new engineering analyses to design appropriate I -Loads and trajectories, but updates to software 
tools and procedures. 

Other changes originated from within the mission operations community. One such change was the introduction of 
the option to intentionally delay the abort to a TAL site. For a typical TAL abort, the vehicle would begin steering 
toward its TAL runway shortly after the abort was declared. For missions to the ISS, this meant steering away from 
the U.S. East Coast. However if there were to be a second failure of an SSME shortly after TAL was declared, the 
vehicle might need to steer back toward the East coast in an attempt to complete a contingency landing. The idea of 
a delayed TAL was to not declare TAL immediately upon the recognition of the need to abort; rather, the situation 
would be monitored, during which time the vehicle continued to stay close to the east coast. If no other failures 
occurred, a TAL would be declared in time to achieve a successful landing. If a second failure did occur, the 
capability to land somewhere on the east coast had been improved. TAL delay was a fairly straightforward idea that 
arose from the mission operations community and was implemented fairly rapidly via Flight Rule update. However, 
AFD incurred a significant analysis cost to first verify the idea could work as planned, to update mission planning 
design systems and processes and then to generate trajectories and associated data to feed the operations team for 
use during training simulations and real-time support. The wide variety of scenarios involved drove the analysis size 
and complexity: launches at various times in the launch window (which affects the proximity of the groundtrack to 
the east coast, and therefore the landing capability), failures at different mission elapsed times (which drive abort 
performance and capability), variability in the duration to delay the TAL abort action, landings to three different 
potential TAL sites, and landings to multiple different east coast contingency sites. 
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Finally, still more changes originated from within AFD. For example, the process improvement efforts described 
above (ISS Standardization and JITFD) resulted in numerous impacts to procedures, tools, and training materials. 

B. Examples of mitigation strategies 

AFD developed specific mitigation strategies to accommodate changes. Three that will be discussed here are process 
documentation, a change evaluation system, and an anomaly reporting system. 


Process documentation included procedures, checklists, and training materials. This information served as the 
foundation of knowledge about the way things worked in AFD. The backbone of the documentation was the Flight 
Design Handbook, which was a multi-volume set of procedures governing mission design processes. The collective 
documentation served an especially important role due to the long duration of the SSP; over the SSP’s 30 years 
personnel tended to turn over and corporate knowledge could be lost if it was not written down. A solid 
documentation base was a key to understanding process baselines, such that impacts due to a particular change could 
be properly understood. 


A second key mitigation strategy was a formal change evaluation system. This system included a Design Impact 
Form (DIF) and a Design Impact Database (DID). Figures 4 and 5 shows representative entries made into the DID. 

’ ptnZj!7l2oo55i7 
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Figure 4: Representative example of DIF entries in the DID (Page 1). 
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Figure 5: Representative example of DIF entries in the DID (Page 2). 


When a new change was identified, a DIF would be filled out to capture the change. The DIF was then circulated to 
the AFD lead engineers, who would perform an impact assessment. The form included a checklist of memory- 
joggers to help the lead engineers evaluate all aspects of the change (procedures, software, training materials, etc.). 
It was important to consider the full effect of the change not just within the changed system, but to adjacent systems 
and operations. The impacts were collected and entered into the DID. 


The system was closed-loop in the sense that impacts led to action items that were formally tracked to closure. In 
addition, the entire team of lead engineers had insight into the impacts, which significantly increased the likelihood 
of identifying second-order ripple effects (e.g., “if the Aborts discipline changes their product, software or 
procedures, the Range Safety discipline will need to change theirs as well”, or “if the engine or model characteristics 
are changed, then one may need to redesign hardware -dependent flight software guidance and sequencing 
parameters”). To give the reader a feel for the need for this type of system, the DID contains thousands of records of 
changes that were evaluated and implemented by flight design disciplines from 1994 to 201 1. This same system 
was also used to formally respond to program change instrument evaluations and document approval, comments 
with changes, and disapprovals with rationale for later consideration by SSP program technical panels and control 
boards. 
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A formal anomaly reporting system was also a critical mitigation strategy. Anomaly Reports (ARs) were written to 
document when things did not go as planned. These ranged from serious issues, of which there were thankfully only 
a handful, to smaller items, which represented the majority. It was simple to open an AR - the only information 
required was a description of what went wrong and basic tracking information. 

Each AR was taken seriously, regardless of the severity of the problem that resulted. Personnel were trained not to 
stop when symptoms had been treated, but rather to identify and correct root causes. This philosophy was reinforced 
by documenting not just the immediate correction to the problem, but long-term corrective action which would 
ensure the problem did not happen again. The AR was not closed until after both the immediate and the long-term 
actions had been completed. Over the years the AR system documented hundreds of problems across all flight 
design disciplines, and provided valuable insight into AFD and other processes. Because problems were identified 
and fixed when they were small, it was very rare for a large problem to develop. Figure 6 below shows a blank AR 
form. 
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Figure 6: Blank Anomaly Reporting form 


Summary / Key Takeaways 

Expect change, especially in dynamic areas of human spaceflight. Build processes to accommodate such change. 

• Process documentation serves as the foundation for the organization’s knowledge base. 

• A formal system to evaluate changes can help identify and ensure timely completion of first- and second- 

order impacts. 

• A formal anomaly reporting system can help ensure root causes are addressed so that problems are not 

repeated. 
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IV. Maintaining quality in times of cost reductions and content increases 

Many organizations have been faced with “doing more with less” and AFD is no exception. For AFD, it was 
essential to ensure that quality did not suffer during an environment of cost reductions and content additions. Rather 
than focus on specific headcount numbers, this section will provide an overview of a general management 
philosophy and some specific strategies that led to organizational success. 

Local management in AFD successfully pushed decision making authority deep into the organization. In 1994 AFD 
switched from a hierarchical structure, where the lead engineers in each technical discipline were members of 
management, to a matrix structure, where the lead engineers ran each technical discipline as a self-directed work 
team and a separate set of (fewer) first-line managers oversaw the entire organization. This matrix structure was 
extended to technical disciplines as well, as an individual often had roles in multiple disciplines. In addition, each 
discipline was responsible for all components of the related work, including analysis, mission specific design, and 
real-time support. This was in contrast to other SSP organizations that focused on one (or perhaps two) of those 
three components. To encourage cross-discipline coordination, key formal engineering and software technical 
coordination meetings were established that included lead engineers and subject matter experts. 

Since the management team had responsibility for the overall organization, not a single slice of it, organizational 
issues such as “kingdom building” and “turf wars” were avoided. The management team set department goals, 
established priority lists which reinforced the goals, and deployed resources accordingly in coordination with the 
technical discipline lead engineers. As AFD’s work changed, the management team adapted. For example, they 
recognized an overlap in skills between the group responsible for design of the pre -mission nominal trajectory 
(among other items) and the group responsible for design of the launch day nominal trajectory (among other items). 
The technical groups were merged to eliminate the overlap, enabling a real reduction in AFD’s headcount. 

While the organizational structure helped push decision-making down into the organization, other processes helped 
ensure quality. Examples include process documentation such as the Flight Design Handbook, the DIF/DID system, 
and the AR system, all mentioned above. Another example is the rigorous change control processes used to provide 
configuration management of procedures, software tools and associated data. In addition, AFD relied on technical 
training programs not just for junior engineers but for experienced engineers as well, to ensure all personnel were 
constantly developing new skills. 

These strategies allowed AFD to expand its responsibilities over time, while maintaining the high quality absolutely 
essential to a human spaceflight program. For example, in 1996, a new contract called the Space Flight Operations 
Contract (SFOC) was introduced. Under SFOC, flight design, including AFD, became a contractor-accountable 
function with reduced government involvement required. In 1998, the Space Shuttle Program Office transitioned co- 
ownership of the requirements management of Space Shuttle FSW guidance, navigation, and cockpit display 
principal functions to AFD. Also in 1998, the government transitioned co-ownership of I-Load management to 
AFD. In each case, the complementary co-owners were assigned from the systems integrationorganization. This 
synergy between operations and the systems integration organization was healthy and essential to ensure that design 
changes were informed with operations expertise and impacts. The addition of flight software principal function 
requirements management and I-Load management and ownership significantly expanded AFD’s responsibilities 
within the SSP, and introduced the new positions of AFD Principal Function Manager (PFM) and AFD I-Load 
Owner (ILO). Such heightened ownership and responsibility under the SFOC also led to AFD taking the SSP lead 
or providing key contributions in authoring and implementing some of the marquee guidance and navigation 
changes in the Shuttle program. These changes included the development of onboard GNC uplink capability (01- 
26, 01-28, 01-29), GPS (01-27), updates to ascent guidance algorithms to allow variable SSME throttle limits as a 
function of abort mode to provide the SSP the flexibility to properly manage ascent abort risk, the onboard 
calculation of the navigation rotation, nutation, and precession (RNP) matrix (01-29) to accommodate launch delays, 
and key updates to the crew trajectory reference displays for increased situational awareness during ascent/entry 
(01-32, 01-33). Adding such visible and important roles as PFM and ILO to AFD also improved the overall skill 
mix, by retaining high-caliber personnel to perform the roles. This had a positive effect on quality as well. 
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US human spaceflight programs have had a continuous focus on quality and safety, starting with the Mercury 
Program and continuing through today (see Figures 2 and 7). This focus clearly left its mark on the AFD 
organization. 
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Summary / Key Takeaways 

Considering the success in the AFD implementation of quality processes, the reliability is in the pudding as the 
success of this mission planning system can now be measured over literally hundreds of mission planning cycles. 
Key takeaways are: 


Management philosophy will impact the organization’s chance of success. 

• For AFD, a matrix organization model was a key to successfully “doing more with less.” 
Organizational processes help ensure quality. 

• For AFD, these included change control processes and technical training programs. 

Expanding an organization’s responsibilities can help ensure quality. 

• For AFD, the transition to FSW requirements management, trajectory design and reconfiguration 

responsibilities via the PFM and ILO roles had a positive impact on quality. 


V. Additional Operations Experience & Lessons Learned 

AFD experience yields multiple additional lessons learned regarding ascent flight design and operations that are 
only briefly summarized below. Key categories of lessons include FSW requirements, trajectory design and 
verification, and I-Load reconfiguration and uplinks. 

A. FSW Requirements 

Key takeaways from the AFD experience regarding flight software requirements management include: 

• As mentioned above, AFD PFMs and ILOs shared ownership of guidance and display functions with another 

organization. Dual ownership allowed AFD to provide the operations experience to inform the design 
baseline, a perspective that would have otherwise been missing; similar ownership arrangements should be 
considered for future programs. 

• When designing FSW, carefully consider costs/benefits of providing automation capabilities on-board, versus 

relying on mission-to-mission I-Load reconfiguration. It may be possible to reduce sustaining engineering 
costs during the operations phase by pursuing closed-loop guidance functionality, especially for dynamic 
flight phases or events. However, such automation will come at a price during the development phase. 

• Ensure that FSW requirements have an ability to completely inhibit new functionality, to allow staged 

implementation of updates between major FSW upgrades. There were cases where SSP FSW updates were 
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left inhibited (i.e., not turned on) due to programmatic decisions, and the option of leaving the update “off’ 
avoided significant rework that would have been required to back out the change. 

• Strive for consistency between design and verification requirements and documentation, at all levels of the 

program. For SSP, AFD interfaced with multiple verification systems on different platforms, which at times 
led to different constraints with multiple purposes . 

B. Trajectory Design and Verification 

Key takeaways from the AFD experience regarding trajectory design and verification include: 

• Avoid the temptation to limit the verification trajectory case matrix to representative trajectory cases based 

on engineering judgment. Rather, as sometimes more is better, favor a comprehensive verification approach 
for trajectory types associated with dynamic flight phases and events, especially when computing power 
allows full trajectory scans and the generation of automated verification constraint reports. Such 
approaches can identify verification and certification “holes” early in the design and operation phases. 

• On the other hand, avoid the temptation to implement over-automated design and verification processes 

(“single pushbutton” methods). Rather, design tools with key checkpoints to allow for intervention to 
iterate or resolve issues. 

• Implement trajectory and I-Load constraint checks as far upstream as possible and in as few design, 

verification, reconfiguration and command systems as beneficial to avoid unnecessary overhead and 
oversights. 

• Ensure that I-Load constraint checks represent and are tested for the full operational envelope. 

• Document performance studies and analyses for later reference or re-use, such as for abort improvement, 

abort gap closure and no-fail performance improvement efforts. These topics seemed to resurface again and 
again; a full cognizance of prior work, including ground rules and assumptions, went a long way in 
ensuring AFD did not have to “reinvent the wheel” each time. 

• Implement a mission change tracking system for all program elements to ensure a common generic and 

mission- specific requirements baseline. For SSP, a system existed to capture the proper version of each 
requirements document, and any program-approved overrides or deviations. This went a long way in 
ensuring commonality between numerous organizations for design, verification, reconfiguration, training, 
and flight. 

• Ensure that trajectory design and verification organizations have access to simulations that include embedded 

actual flight software to allow for analysis of intricate software initialization, sequencing and other 
performance issues. 

• Require that design and verification mission planning processes avoid the use of hardcoded system limits to 

maintain flexibility and avoid costly upgrades.. 

C. I-Load Reconfiguration and Uplinks 

Key takeaways from the AFD experience regarding I-Load reconfiguration and uplinks include: 

• Ensure data compatibility between onboard and ground systems. 

• Implement a smart selection criteria process to reconfigure large datasets that are static or can be mapped 

against repeatable mission characteristics. 

• Implement rigorous transfer QA requirements to ensure not only that the data is correct, but that the data was 

successfully transferred for testing, training or flight and is applicable to the mission at hand. 

• Avoid the use of derived I-Loads (i.e., prior to uplink to the FSW, one I-Load’ s value is calculated based on 

another I-Load’ s value). SSP’s use of derived I-Loads initially reduced the onboard code count yet 
increased the verification costs via additional I-Load audits and patch verification efforts. 

• Establish a clear definition of required I-Load uplink content early in the program, to avoid later 

implementation costs. Preferably, allow the uplink of all reconfigurable parameters while allowing the 
administrative/management process to constrain what parameters may be updated. 

• Retain key reconfigured or uplinked data on major operational FSW transitions, such as ascent to entry. For 

SSP, some uplinks (e.g., landing site table I-Loads) were lost on this transition thus increasing operations 
cost. 
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VI. Conclusion 

The AFD team has directly contributed to the success of the SSP via innovation and sustained reliability through 
incremental evolution. Strategic initiatives, such as moving the work as late as possible and reducing cycle times, 
helped provide the SSP with the flexibility necessary to take advantage of the Space Shuttle’s remarkable 
capabilities. Change management processes ensured that AFD procedures, software tools, and training materials 
kept pace with the frequency and complexity of updates originating at all levels of the SSP. And right through the 
end of more than 30 years of Space Shuttle ascent operations marked by the successful launch of STS -135/Atlantis 
on July 8, 201 1, despite cost reductions and work content additions, AFD maintained the exceptional quality 
required of a human spaceflight program. In these ways, AFD was creative in designing and implementing strategies 
to ensure their success. In all cases, these successes can be directly attributed to the same safety culture that has been 
honed throughout all US human spaceflight programs. The challenges encountered, and the mitigation strategies 
implemented, point to lessons learned that may be applicable to similar work on future programs. 

Nomenclature 


AFD 

= 

Ascent Flight Design 

AR 

= 

Anomaly Report 

ATO 

= 

Abort To Orbit 

BFS 

= 

Backup Flight System 

CGx 

= 

Longitudinal center of gravity 

DID 

= 

Design Impact Database 

DIF 

= 

Design Impact Form 

ET 

= 

External Tank 

FDRD 

= 

Flight Definition and Requirements Directive 

FOP 

= 

Flight Operations Panel 

FSW 

= 

Flight Software 

GNC 

= 

Guidance, Navigation, Control 

GPS 

= 

Global Positioning System 

I-Load 

= 

Initialization Load 

ILO 

= 

I-Load Owner 

ISS 

= 

International Space Station 

JITFD 

= 

Just In Time Flight Design 

KSC 

= 

Kennedy Space Center 

L- 

= 

Launch minus 

MCC 

= 

Mission Control Center 

MECO 

= 

Main Engine Cut Off 

01 

= 

Operational Increment 

OMS 

= 

Orbital Maneuvering System 

PASS 

= 

Primary Avionics Software System 

PFM 

= 

Principal Function Manager 

QA 

= 

Quality Assurance 

RNP 

= 

Rotation, Nutation and Precession 

RTLS 

= 

Return to Launch Site 

SAIL 

= 

Shuttle Avionics Integration Laboratory 

SFOC 

= 

Space Flight Operations Contract 

SMS 

= 

Shuttle Mission Simulator 

SPF 

= 

Software Production Facility 

SRB 

= 

Solid Rocket Booster 

SSME 

= 

Space Shuttle Main Engine 

SSP 

= 

Space Shuttle Program 

STS 

= 

Space Transportation System 

TAL 

= 

Transoceanic Abort Landing 

TDDP 

= 

Trajectory Design Data Package 
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Background / Introduction 


Vv\\ 

The Ascent Flight Design (AFD) team defines a launch to 
orbit operational trajectory profile 

— Satisfies programmatic mission objectives 

— Defines the ground and onboard reconfiguration requirements 

Design, verification and reconfiguration process ensures 
that all mission scenarios are enveloped within integrated 
vehicle and spacecraft certification constraints and criteria 

— Mission scenarios include nominal ascent and both uphill and ground-to- 
ground aborts 

— Intact aborts are protected to a robust level similar to the no-fail, and 
ensure the safe return of the flight crew and the Orbiter for reuse 

Ascent trajectory design and mission planning has evolved 

— Improve program flexibility, reduce cost, while maintaining quality 
An ongoing process throughout 135 missions 

aja United Space Alliance 
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Background / Introduction 



■ Products are used in crew and flight controller training, 
avionics flight software verification, and operations 

■ These products provide the flight crew, flight control 
team, and various support facilities the insight and 
situational awareness necessary for 

— Trajectory and flight dynamics 
— Performance and event sequences 
— Abort mode boundaries and moding 

— Flight performance and impact predictions for launch vehicle stages 
(Range Safety) 

— Flight software performance 
— Tracking systems 
— Launch collision avoidance 

- Day of launch performance, targeting and onboard GNC updates 
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: Program Flexibility 

Space Shuttle was an incredibly capable vehicle 

Accommodated a wide variety of missions 
— No-fail and abort designs had to address significant variations in 

■ Orbital inclination and altitude 

■ Propellant loads 

■ Mass properties 

■ Launch environment 

rogram processes 
... 


— Initially evolved out of a development program 

— Lacked flexibility in handling dynamic manifests, high flight rates, 
changes to baseline mission requirements and hardware mods 

— Were a significant challenge in the presence of tight budgets, the 
need to upgrade aging vehicles/facilities and need to perform 
safety modifications 
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Challenge: Program Flexibility 

■ Solution: Move the work as late as possible 

(1) Flight Operations Reinvention and ISS Standardization efforts 

— Removed training support products from the critical path 

Used standardized trajectories/products for crew/controller training 
— Moved ascent/entry designs closer to launch where manifest stable 
— Reduced the probability of late changes with reassessment/rework 





Milestone 

Base Schedule 

ISS Standardization 
Schedule 


Trajectory Design Initialization Data 

L-303 days 

L-198 d 


Design Start (FOP meeting) 

L-288 d 

L-178 d 


Design Submit (1-Load) 

L-233 d 

L-128 d 


Design Approval (1-Load) 

L-210 d 

L-105 d 


SMS/MCC Load releases 

L-127 d 

L-29 d 


Ready-for-Training 

L-126 d 

L-28 d 
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: Program Flexibility 

Solution: Move the work as late as possible 

(2) Just In Time Flight Design 

- Follow-on and worked in conjunction with ISS Standardization 

Created more efficient flight design process via the reduction in internal 
hand-offs, redundant QA steps and duplication of efforts that crept into 
the system over the first two decades 

Added a smart design initialization process to establish a high quality 
baseline from which the design could be matured 

Took good advantage of client server parallel processing capabilities to 
process a high number of iterative trajectory performance trades and 
optimization tasks 

Design cycle times had been reduced from seven to five weeks 
Allowed for much quicker technical assessments and fast-track analysis 
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: Program Flexibility 

Solution: Move the work as late as possible 

(3) Expanded GNC Initialization loads (1-Load) parameter uplink 

— I-Loads are used to overwrite values of critical GNC parameters resident in 
the flight software with a new value 

1-Load uplinks use dedicated ground and onboard flight software to 
update 1-Loads on day-of-launch 

For much of the SSP, ascent/abort related uplinks were limited 
First stage boost pitch/yaw profile, throttle commands, winds 
Orbital plane steering target, and insertion burn targets 

— Later flight software upgrades included additional uplink capability 

■ No-fail and abort powered flight targets, and key GNC parameters 
that are sensitive to vehicle mass and performance such as Orbiter 
propellant dump durations and capability boundary velocity switches 

— STS-110 was the first flight to incorporate a full complement of uplink 
upgrades (April 8, 2002 launch) 
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Challenge: Program Flexibility 

■ Solution: Move the work as late as possible 

(4) Late Design Cycle 

— Prior to the expanded GNC 1-Load parameter uplink capabilities 

Each significant mission configuration change often involved detailed re- 
assessments 

If an issue was found, then often GNC 1-Load parameters needed updates and 
an "1-Load Patch" to the flight software was necessary 

These patches were intrusive, costly and time-consuming due to the nature of 
patch parameter processing via the software production facility, the 
verification and approval process, the patch build and testing efforts 

— AFD instituted abbreviated design cycle beginning 30 days before launch 

Two week effort to redesign/re-verify the trajectory design profiles 

Final two weeks were reserved for independent flight readiness verification by 
the systems integration organization and to allow for program reviews in 
support of Certification of Flight Readiness (CoFR) 

Late changes were now assessed against this uplink capability 

Significantly reduced 1-Load patch and verification efforts 

Very beneficial to the ISS assembly missions united Space Alliance . 
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: Program Flexibility 


Summary / Key Takeaways 

The SSP had matured in reliability and cost of operations due to 
evolutionary improvements of the mission planning process 

Trajectory design was performed as close to launch as possible, 
ideally after all critical mission attributes had been frozen 

— Key enablers for late design efforts were to 

decouple the mission specific trajectory design from crew and flight 
controller training 

Implement a short duration trajectory design and verification 
process 

Update the trajectory and mission configuration sensitive GNC I- 
Load parameters close to launch via prelaunch uplink 
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: Managing Change 


Change management processes are critical 

Success of a program is rooted in its ability to control its 
processes, evolve and grow to reduce cost and improve reliability 
and operability 

AFD wa$ dependent on multiple requirements and data 
sources from multiple organizations across the country 

— A change in any corner of the program could create an impact to 
planning and real-time software tools/simulators, design 
processes, products or personnel training 


— At peak activity, the group interacted with over 90 standing 
technical panels, control boards and technical interchange groups 

— It was imperative that AFD develop good engineering habits and 
change management processes 
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: Managing Change 

Another consideration was the size and complexity of 
mission planning systems and processes 

— Hundreds of software tools, millions of source lines of code 

— Thousands of engineering, operations and software documents 

— Thousands of analyses and mission products 

To maintain safety, the application of proper mission 
design, constraint definition, trajectory control limits and 
operational procedures is essential 

— No different than for Mercury, Gemini, Apollo, Skylab, ASTP 
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Challenge: Managing Change 

Mitigation Strategies 

Process documentation 

Engineering and operational procedures, process checklists, and 
training materials 

Foundation of knowledge, and a solid documentation baseline that 
was key to understanding process baselines such that change 
impacts could be properly understood and implemented 

Such documents are critical especially in a 30-year program 

Change evaluation system 

Change ipnpacts were evaluated via the use of a Design Impact Form 
(DIF) and Design Impact Database (DID) 

Allowed the change evaluation to reflect all process impacts, all 
stakeholders, mission impacts 

AI|o used for formal responses to program change instrument 
evaluations and concurrence/disapproval 

— An Anomaly Reporting (AR) system to document immediate and 
long-term corrective actions + united space Alliance iG&K 
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Challenge: Managing Change 

Example Design Impact Form (subset) 



|DIF Num:||20Q3-Q17 DIF Open Date; 01/15/2003 Related_DIF | 


PCIN SR DR etc Nun! PCIN S0420I3DU 


I Initiator: 


Responsible Engineer: I Con /Car 


/Pic 


I Department: 


T itle l Authorize 109% ntact Abort Throtle for Flight Design. 


r Evaluaiion 

O 

FDD Change 

r 

Sign OH 


Closed 


Final Approval Board | PR CB 


T ask Description: 





| SSP Documents Affectec| 

IlNSTS 07700 Volumes !ll,X| 


Effectivitv: flNFS 


Update NSTS 07700 Volume III to include use of 1 03% SEME power level on Intact aborts. Also update PE ^ || 
Utilization Matrix consistent with certification for use of 1 06% and 1 03% power levels. 

Directive issued 2/03/03 with multiple actions: 

1. PROVIDE STATUS ON 1 06% NO -FAIL ULLAGE PRESSURE ISSUE. Deferred ta 5/22/03. 

2. REVISE NSTS 07700, VOLUME X, BOOK 1 TO REVISE A TABLE IDENTIFIER FOR SSME 

operating! 

CHARACTERISTICS. DOCUMENT SSME PL PERFORMANCE AND SERVICE LIFE REQUIREMENTS 
CONSISTENT WITH SLOCK II AS INDICATED IN ATTACHMENT B OF PFCElD S042013DU. 3/22/03. 


I Last Edited By: 


T I Date Last Edited: 


Date Eval Required: | 


(Date Resp Required: |[ 


Nominal Intact Contingency ARD Range Safety Post MECO Database AME ADSSP DOL FDE Abort Sup 
Evaluation J7 p J7 W 

Evaluation: 

After completing the PRCB action to evaluate the risk in using the 103% Intact Abort Throttle^ this action updates program documentation to 
allow the use of the new performance settings in (sight design. 

T his PCIN changes the NSTS -07700 documents (Vol. Ill and Vol. %) to be compatible for throttle limits up to 1 03%. A separate PDN is 
expected to address subordinate SSP document updates (NSTS-0S20S Vol. 1, 3, and 4). 


Risk Assessment: 

Approve with Comments. In the Reason for Charge, the sense of the change is to incorporate specific "evels of 
I 06% and 1 09% when the description should implp use up to the levels. For example, the seccnd sentence might: 
read "...the use of the SSME s at RPLs up to 1 03% for intact aborts. .". When a flight is manifested with 1 03% abort 
throttles, it doesn't imply that all engine failure times lead to a throttle-up to 1 09%. Flight software allows us to 
design aborts so that for a range of engine failure times., if the abort Ihrottle-up isnt required to complete the abort 
then the engines will stay at 1 04.5%. A typical RTLS would fall into that category. THs pattern is followed in the 
proposed changes. With the purpose of the directive to alow cons deration of requirements up to the certified 

^ United Space Alliance 
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: Managing Change 


Summary / Key Takeaways 

— Expect change, especially in dynamic areas of human spaceflight 

— Build processes to accommodate such change 

Process documentation serves as the foundation for an 
organization's knowledge base 

— A formal system to evaluate changes can help identify and ensure 
a timely completion of first and second order impacts 

— A formal anomaly reporting system can ensure root causes are 
addressed so that problems are not repeated 
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: Maintaining quality 


■ US human spaceflight programs have had a continuous 
focus on quality and safety 


Already mentioned: process documentation, DIF/DID system, and the AR 


Rigorous change control processes to provide configuration management 
of procedures, SW tools and associated data 

— Reliance on technical training programs for junior and experienced 
engineers to ensure development of new skills 

■ These strategies allowed AFD to expand responsibilities 

— Reduced government involvement via contract allowed AFD to take 
ownership of key contractor accountable functions 

— Program transitioned ownership of requirements management of Space 
Shuttle flight software and 1-Load functions to AFD for ascent/entry/on- 
orbit guidance, navigation and cockpit display 

— AFD took the lead in authoring key GNC capabilities and was able to 


■ Various processes enhanced quality 



system 
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Challenge: Maintaining quality 


■ A\ was essential to ensure quality in an environment of 

cost reductions and content additions 

■ Decision making authority was pushed deep into the 
organization which improved quality and timeliness 

— Old organization was vertically aligned with lead engineers as members 
of line management 

— Evolved to lead engineers running technical disciplines as self-directed 
work teams; a small set of line managers oversaw the organization 

— Eliminated kingdom building and turf wars 

— Management team set goals, priority lists which reinforced goals, and 
deployed resources accordingly in coordination with lead engineers 



United Space Alliance 
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: Maintaining quality 

Summary / Key Takeaways 

— AFD processes and mission planning systems were successful in 
maintaining a high level of quality and safety, measured over 
hundreds of mission planning cycles 

Management philosophy will impact an organization's chance of 
success, and a matrix organization model was key in doing more 
with less 

Organizational change control processes and technical training 
programs are key in ensuring quality 

Expanding an organization's responsibilities can help ensure 
quality such as requirements, design and reconfiguration 
responsibilities 


United Space Alliance 
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Challenge: Additional Operations 
Experience & Lessons Learned 

Flight Software Requirements 

— Consider dual ownership of requirements for GNC flight software 
and GNC I-Load parameter management between development 
and operations organizations 

— Perform careful cost/benefit trades of providing automation 
capabilities onboard vs. relying on mission-to-mission 1-Load 
configuration 

ij // jjl 

— Ensure that flight software upgrades include an ability to fully 
inhibit all new functionality to 

■ allow staged implementation of updates between major software 
upgrades, and to 

=*=avoid significant rework to back out a change 

— Strive for consistency between design and verification 
requirements and documentation to avoid reqt's creep/cost 
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Challenge: Additional Operations 
Experience & Lessons Learned 

v\\ 

■ Trajectory Design and Verification 

Identify verification and certification "holes" early in the design and 
operations implementation phase 

■ Avoid the temptation to oversimplify trajectories and flight dynamics by 
prematurely picking a small subset of representative cases 

— Avoid the use of over-automated design and verification processes/tools 

■ Design tools/processes with key checkpoints to allow for intervention to 
iterate or resolve issues 

— Ensure that trajectory constraint checks represent and are tested for the 
full operational envelope 

— Implement a mission change tracking system for all program elements 

■ Ensure a common generic and mission-specific requirements baseline 



Ensure commonality between numerous organizations for design, verification, 
reconfiguration, training and flight 


— Use simulations that include embedded actual flight software 

■ Allows analysis of intricate software initialization, sequencing and 


performance issues 
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Challenge: Additional Operations 
Experience & Lessons Learned 

■ Initialization Load Reconfiguration and Uplinks 

— Ensure data compatibility between onboard and ground systems 

Implement a smart selection criteria process to reconfigure large datasets 
that are static or that can be mapped against repeatable mission 
characteristics 

Implement rigorous transfer QA requirements to ensure that data is not 
only correct but that it is the right data for the task at hand 

To limit downstream costs, implement the mechanism to allow the uplink 
of any GNC parameter; procedures can control which parameters are 
available/authorized for uplink 
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The AFD team has contributed to Space Shuttle Program (SSP) 
success via innovation and sustained reliability 

— Incremental evolution of ascent flight operations through 30 
years and 135 flights 

Strategic initiatives helped the SSP achieve the desired flexibility by 
moving critical work late as possible and by reducing cycle times 

Change management processes ensured that AFD procedures, tools 
and training materials kept pace with the frequency and complexity 
of SSP updates 

Despite cost reductions and work content additions, AFD maintained 
the quality required of a human spaceflight program 

Successful ascent flight operations can be attributed to the same 
safety culture that has been present in all US human spaceflight 
programs 

Challenges and mitigation strategies point to lessons learned that 
may apply to similar work on future programs 

^ United Space Alliance 
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